1. Field of the Technology
The present invention relates to IP Multimedia Subsystem (IMS) network in the communication field, more particularly to a method, system and equipment for processing Session Initiation Protocol (SIP) requests in IMS network when an Application Server (AS) is taken as a Back-to-Back User Agent (B2BUA).
2. Background of the Invention
In an IMS network, the Serving Call Session Control Function (S-CSCF) entities generally do not execute specific service and the service logic is placed in the AS. Upon receiving a SIP request, the S-CSCF searches the User Profile (UP) downloaded during the registration of the user for the initial Filter Criteria (iFC) matching with the SIP request and forwards the SIP request to the relevant AS based on the rule of iFC. The AS can serve different roles for IMS dialogs. If the AS serves as the dialog originator, as shown in FIG. 1A, the AS originates a dialog and sends this dialog to the S-CSCF, and the S-CSCF will not change relevant information of this dialog. If the AS serves as the B2BUA, as shown in FIG. 1B, the AS receives the SIP request sent by the S-CSCF, it ends that dialog and initiates a new dialog, and the association between the two dialogs is performed by the AS, but from the aspect of S-CSCF, since the two dialogs are different, the relevant information, such as Call-ID and from/to tag, of one dialog is different from that of the other.
In the mode when the AS serves as the B2BUA, however, the S-CSCF often needs to know the association between the two dialogs since the user may still hope to adopt the iFC of the original dialog for the new dialog. Because the two dialogs are different, the two dialogs must be associated by using other identifiers in the SIP requests, like Orig-DIALOG ID in Route header, rather than directly using SIP dialog identifiers like Call-ID.
Several headers of the SIP request closely related to the present invention will be briefly described hereinafter:                Route header: indicating the next routing entity, i.e., the next hop of the SIP request, and may include the Orig-DIALOG ID which is used to assist the S-CSCF in learning the corresponding relation between the new dialog and the original dialog;        P-Asserted-Identity header: a user identifier inserted by a network entity and identifying the originator that originates the request;        Request-URI header: indicating the request's final destination.        
When the AS acts as the B2BUA, the AS decides whether the new and original dialog need be associated based on the specific service logic. Moreover, the AS can also modify the Request-URI header or P-Asserted-Identity header included in the SIP request based on the specific service logic.
According to the existing protocol specification, when the S-CSCF is sending a SIP request to the AS, the S-CSCF must place the Uniform Resource Identifier (URI) of the S-CSCF that includes an Orig-DIALOG ID in the Route header, behind the AS URI. In this way, upon receiving the SIP request, the AS removes the topmost part of Route header i.e., AS URI, therefore S-CSCF URI is the topmost part of the Route header. The AS transmits the SIP request based on the Route header information, such that the SIP request will be transmitted to the S-CSCF. Upon receiving the SIP request, the S-CSCF decides whether the SIP request is initiated by the AS or has been processed by the S-CSCF before transmitted by judging whether the Route header includes an Orig-DIALOG ID, and if it is determined that the SIP request is processed by the S-CSCF before, the S-CSCF determines the original dialog to which the current dialog is associated according to the Orig-DIALOG ID carried in the Route header of the SIP request and further performs the incomplete iFC process to the current dialog.
The specific process of associating the new dialog and original dialog can be described in detail by describing the operations of the S-CSCF and those of the AS respectively.
Operations of the S-CSCF:
1. Upon receiving a SIP request, if the S-CSCF finds that this request includes an Orig-DIALOG ID, the S-CSCF determines that this request has been processed by the S-CSCF before. According to the Orig-DIALOG ID, the S-CSCF finds the original dialog and, when confirming that the related user identifier is unmodified, say on the calling side the P-Asserted-Identity has not been modified or on the called side the Request-URI has not been modified, continues to execute the incomplete iFC process.
2. Upon receiving the SIP request, if the S-CSCF finds that this request includes no Orig-DIALOG ID, the S-CSCF determines that this request corresponds to a new dialog originated by the AS. The S-CSCF decides how to process the request according to the iFC matching with this request. If the S-CSCF needs to forward this request to the AS, the S-CSCF fills the AS URI and the S-CSCF URI in the Route header in sequence, and the S-CSCF URI includes an ORIG-DIALOG ID. An example is as follows:                ROUTE <AS-URI; >; <Orig-DIALGO ID@S-CSCF1;>.        
Therein, the Orig-DIALOG ID can also be indicated by other identification such as specific port.
Operations of the AS:
1. Upon receiving the SIP request and executing relevant operations, the AS determines its own role during this dialog according to the service logic and determines how to generate new SIP requests. If the AS serves as the B2BUA, the AS should remove its own AS URI from the Route header of the original SIP request, copy the rest of the Route header to the new request as the Route header of the new request and route this new request according to the Route header. Therefore, a URI in the new request, which corresponds to the S-CSCF and includes the Orig-DILOG ID, will be placed at the top of the Route header.
Therefore, the AS URI is removed from the Route header in the new request by the AS, so the S-CSCF will receive a request that includes the following Route header:                Route <Orig-DIALOG ID@S-CSCF1;>□ . . .        
In this way, upon receiving the SIP request returned from the AS, the S-CSCF can determine the original dialog to which the received SIP request associates according to the Orig-DIALOG ID and execute subsequent iFC process after confirming that the relevant user identifier is unmodified.